REMARKS 

This Amendment is in response to the Office Action dated September 12, 2007 in 
which the previous claim rejections were withdrawn and replaced with a new ground of rejection 
based on a combination of Bowen (previously applied) and Duboc et al. (newly applied). 

Applicants respectfully request reconsideration and allowance of all pending 
claims since the newly cited Duboc et al. reference does not disclose the elements of Applicants' 
claims as suggested in the Office Action. Thus, the proposed combination with Bowen fails to 
anticipate each and every limitation of at least the independent claims. 

1. CLAIM REJECTIONS UNDER §103 BASED ON BOWEN AND DUBOC ET 

AL. 

Claims 1-3, 5-11 and 13-20 were rejected under § 103(a) as being allegedly 
unpatentable over U.S. Publication No. 2002/0100029 to Bowen in view of U.S. Patent No. 
6,425,1 16 to Duboc et al. 

A. Claim 1 

Claim 1 includes the steps of configuring a function block to instantiate a 
hardware description with options associated with different configurations of the peripheral 
device, and selecting between the options at compile time for each instantiation of the peripheral 
device without modification to the hardware description . 

B. Bowen 

1. Options are Not Selectable Without Modification To the Hardware 
Description 

The Office Action inaccurately suggests that, in Bowen, the options are selected 
without modification to the hardware description, citing paragraph [0036]. 

Paragraph [0036] states, "a hardware compiler for producing from those parts of 
the specification partitioned to hardware a register transfer level description for configuring 
configurable logic resources." 

The register transfer level description configures the configurable logic resources 
according to the input provided to the hardware compiler. The input provided in the hardware 
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compiler contains a pre-defined configuration that is used for configuring the configurable logic 
resources, such as during synthesis at step 214 in Figure 2. The input itself is not configurable at 
compile time. Rather it is predetermined by the C code. Thus, a configuration change would 
require a change to the hardware description. 

Bowen does not disclose that such options are selected without modification to 
the hardware description. 

2. Bowen Does Not Disclose Selecting Between the Options at 
Compile Time for Each Instantiation of the Peripheral Device 

The Office Action acknowledges that Bowen does not disclose "configuring a 
function block to instantiate a hardware description with options associated with different 
configurations of the peripheral device, and selecting between the options at compile time for 
each instantiation of the peripheral device," as recited in claim 1. 

In contrast, in one non-limiting example of the present application, RTL is coded 
in a way to be reusable so that different configurations can be used in a single chip (where the 
configuration options are selectable at compile time) without modifying the RTL for each 
instance. 

C. Duboc et al. 

1. Duboc et al. Fails to Disclose That Two Different Instantiations 
Can Have Two Different Configurations Selectable at Compile 
Time 

The Office Action states Duboc et al. shows compiling the hardware description 
to produce a model comprising each instantiation of a peripheral device with the selected options 
of the different configurations for that instantiation (citing Duboc, col. 8, lines 33-39; col. 10, 
lines 31-34). 

Doboc et al. generally discloses a way to take existing building blocks and user 
input to make RTL, reduce to gates, and make an integrated circuit. Duboc et al. does not 
disclose using the same building block more than once with different input from the user in the 
same IC. 



Column 8, lines 33-39 mentions using the GUI input to initiate generation of the 
IC design via selection of a "compile option" from the GUI window, resulting in the execution of 
a script engine that verifies parameters input by a user. 

In Duboc et al., the user configures the IC once. In the example described in 
column 6, lines 47-57, they are making one custom DSP IC. Looking at the options of Table 1, 
the user picks one Data Y ROM size to make this one custom DSP IC. The user does not run 
the GUI (or a template) twice to have two or more custom DSP configurations (different DSP 
instances) on one IC. Rather, the user runs through the GUI once and it configures the IC. 

For example, there is no an instance identifier in FIG. 6 (so as to independently 
configure different instances in different ways). The Y RAM and X RAM are not two different 
RAM instances, but are tied together with the same configuration (their address space is divided). 
"The Y data space, which is configurable by the user, can occupy the top 2, 4, 8 or 16K of the 
data space, with the remaining data addresses mapped to the X data space." (Col. 6, lines 47-57; 
see also , col. 9, lines 43-47). They are not separately configurable. 

In the present application, the same building block (peripheral) can be used twice 
in the same IC. So, for example, the user could configure the Data Y ROM to be 2K in one 
custom DSP instance on the IC and the Data Y ROM to be 4K in another/different custom DSP 
instance on the same IC. 

Duboc et al. do not disclose that two different instantiations can have two 
different configurations selectable at compile time. Referring to the language of claim 1, Duboc 
et al. do not disclose "configuring a function block to instantiate a hardware description with 
options associated with different configurations of the peripheral device, and selecting between 
the options at compile time for each instantiation of the peripheral device without modification to 
the hardware description ." 

In fact, Duboc et al. do not suggest that such a feature would be desirable or how 
such a feature could be accomplished. The disclosed GUI does not provide that structure or 
functionality. 
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D. Combination of Bowen and Duboc et al. 

Lacking such a disclosure, the proposed combination of Bowen and Duboc et al. 
therefore fails to teach or suggest multiple instantiations of a peripheral device on the same IC 
with different configurations, where the same function block is used to instantiate a hardware 
description with options associated with the different configurations of the peripheral device. 

The proposed combination also fails to disclose a step of selecting between the 
options at compile time for each instantiation of the peripheral device without modification to the 
hardware description . 

Further, there is nothing in either Bowen or Duboc et al. that would make it 
obvious for a skilled person to try. 

E. Dependent Claims 2 and 3 (For Example) 

Claim 2 adds that the step of selecting comprises "passing a parameter value to 
the function block at compile time for each instantiation of the hardware peripheral." 

Claims 3 describes that the configuration options are peripheral design functions, 
peripheral design pin widths, or peripheral design interface pin outs. 

Again, neither Bowen nor Duboc et al. disclose a method in which a parameter 
value can be passed to a function block that is configured to instantiate each instantiation of a 
hardware peripheral, where the different instantiations can have different configurations (per 
claim 1). 

The Office Action cites Bowen paragraph [0037], which states that "The system 
can include a width adjuster for setting and using a desired data word size, and this can be done 
at several points in the desired process as necessary." 

But in Bowen, the same width adjustment would be applied to every instance in 
the design. Paragraph [0114] describes that at 206a and 206b, width adjustment is carried out by 
ANDing bits with a bit mask. This would apply to every instance of the block/code in the design. 

In the present application, the functional block can be configured to use a different 
width for each instance of the block in the design, for example. 
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in addition, one or more other dependent claims add further elements that are 
neither taught nor suggested by Bowen and/or Duboc et al. 

F. Claim 7 

In respect to independent claim 7, the Office Action refers to paragraphs [0009], 
[0031] and [0241] of Bowen 

As discussed above, Bowen does not disclose configuring a function block to 
instantiate a hardware description with options at compile time and instantiating multiple 
instances of the peripheral device on the integrated circuit by programmatically selecting between 
the options at compile time for each instantiation of the peripheral device. 

Paragraph [0241] simply states that the OOP components (reusable software 
modules) are accessed at run-time. 

As described above, Duboc et al. also fails to disclose these elements. 

Claim 7 and its respective dependent claims are therefore not anticipated by or 
obvious over Bowen in view of Duboc et al. for similar reasons as were discussed above with 
respect to claim 1. 

G. Claim 16 

Similarly, independent claim 16 and its dependent claims are not anticipated by or 
obvious over Bowen in view of Duboc et al. for the similar reasons as were discussed above with 
respect to claims 1 and 7. 

m. CLAIM REJECTIONS UNDER §103 BASED ON BOWEN. DUBOC ET AL. 

AND YU ET AL. 

Claims 4 and 12 were rejected under §103 as being allegedly being unpatentable 
over Bowen in view of Duboc et al. and Yu et al., U.S. Patent No. 6,829,754. The combination 
of Bowen, Duboc et al. and Yu et al. does not teach or make obvious the inventions recited in 
claims 4 and 12 for similar reasons as discussed above with respect to the independent claims. 

In addition, page 13 of the office action suggests "one of ordinary skill in the art 
would be motivated to strap the power or ground pins so that the power related problems can be 
avoid[ed]". 
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The strap pins discussed in claims 4 and 12 are not for power related problems. 
They are to tie peripheral input pins logic level high or logic level low (based on the particular 
configuration of that instance) to make a functional decision on different features supported in a 
design. For example, processors and computer systems have the idea of big endian data format 
and little endian data format. These formats specify how bytes are organized in the memory. A 
peripheral can have a static strap pin tied to ground (low) if little endian data format should be 
used or to power (high) if big endian data format is used. The pin is tied high or low during 
configuration. 

The comment the examiner makes about power related problems and the citation 
to Yu column 11, lines 2-5 relate to current flow or power through an actual piece of metal and 
generating a warning if the physical width of the strap is smaller than the power pin to which it 
connects. This has nothing to do with configuring a functional block to tie a strap pin to power 
or ground for implementing a particular configuration of a peripheral device. 

Accordingly, Applicants respectfully request that the objections of these claims 
under §103 be withdrawn. 

The Director is authorized to charge any fee deficiency required by this paper or 
credit any overpayment to Deposit Account No. 12-2252. 

Respectfully submitted, 

WESTMAN, CHAMPLIN & KELLY, P.A. 

By: /David D. Brush/ 

David D. Bmsh, Reg. No. 34,557 
900 Second Avenue South, Suite 1400 
Minneapolis, Minnesota 55402-3319 
Phone: (612) 334-3222 Fax: (612) 334-3312 
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